-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Require JavaInfo on deps, move scrooge srcjar to srcs #523
Conversation
while this is still probably good, this did not solve my problem. somehow, the thrift jars are still showing up on the classpath. |
Is there value in reviewing this or do you want to iterate a bit more until
you find your solution?
…On Fri, 15 Jun 2018 at 23:44 P. Oscar Boykin ***@***.***> wrote:
while this is still probably good, this did not solve my problem. somehow,
the thrift jars are still showing up on the classpath.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#523 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF9KXTbfOtoUnkQRhcr80yCUj2bB9ks5t9BzGgaJpZM4UqGd5>
.
|
it is a short review, not much to it, but I don't think we should merge it if it does not improve matters. I'll try to write a test that asserts that the thrifts don't end up on the classpath. Meanwhile: bazelbuild/bazel#5413 seems to let me bypass (at the expense of very long startup times due to the quadratic algorithm that bazel uses to construct the jars for long classpaths). |
I'll leave this to @ianoc since I'm not sure I understand the change (it seems you're just passing the srcjar in a different way) |
this change lgtm |
scala_library( | ||
name = name, | ||
srcs = [srcjar], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this work? i think the scala_library rule is restricted to only allow actual files in the srcs not targets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(or does it intelligently realize the output file?... interesting)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it does use the output file here. We could be more precise and just list the output filename. That might actually solve the problem.... Maybe by putting the whole target we are sucking up all the deps.
Can you do that? Restrict to only files (in the declaration)?
…On Sat, 16 Jun 2018 at 18:29 ianoc ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In twitter_scrooge/twitter_scrooge.bzl
<#523 (comment)>
:
> scala_library(
name = name,
+ srcs = [srcjar],
(or does it intelligently realize the output file?... interesting)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#523 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF7ZbjZf51DYwk3BeS-CQj4IIOQQ5ks5t9SRogaJpZM4UqGd5>
.
|
okay, @ittaiz @ianoc can you take a look? Basically, I removed all the old crufty hacks we had and just require java providers in all places. With this, we don't mistakenly put a bunch of irrelevant stuff on the path. I added a test that we don't add the thrift jar. This is a bigger change, but takes us towards removing tech debt, so it seems like a win. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good in general.
Please see some comments inside.
scala/scala.bzl
Outdated
@@ -12,6 +12,11 @@ load( | |||
"@io_bazel_rules_scala//specs2:specs2_junit.bzl", | |||
_specs2_junit_dependencies = "specs2_junit_dependencies") | |||
|
|||
load( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leftover?
@@ -26,15 +26,12 @@ def _collect_jars_when_dependency_analyzer_is_off(dep_targets): | |||
runtime_jars = [] | |||
|
|||
for dep_target in dep_targets: | |||
# we require a JavaInfo for dependencies | |||
# must use java_import or scala_import if you have raw files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why keep the “if”? I think you can require the divider on the signature of the attribute and so throw all of the conditionals away
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because scrooge puts everything in the deps sadly... we want to fix it, but one step at a time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scrooge macro puts all the thrift dependencies on the deps. :( we need #510
#!/bin/sh | ||
|
||
if grep -q $1 $2 ; then | ||
echo "ERROR: found $1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add what was expected? Either in the assertion or in the test name since 6 months from now I won’t remember :)
extra_information=_collect_extra_information(ctx.attr.deps), | ||
# unfortunately, we need to see this for scrooge and protobuf to work, | ||
# but those are generating srcjar, so they should really come in via srcs | ||
extra_information=_collect_extra_information(ctx.attr.deps + ctx.attr.srcs), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m sorry but I don’t understand this. Where does scroog euse this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
search for all the extra information in the file. For instance: https://github.com/bazelbuild/rules_scala/blob/master/twitter_scrooge/twitter_scrooge.bzl#L85
Really this is something that should be replaced with #510 but that is staged behind a few layers of tech debt removal (a supported skylark function to compile scala and get a JavaInfo, and a toolchain that sets up all the things we need for scala so we don't have to copy-paste the scala setup for the ctx).
scala/private/common.bzl
Outdated
if JavaInfo in dep_target: | ||
java_provider = dep_target[JavaInfo] | ||
current_dep_compile_jars = java_provider.compile_jars | ||
current_dep_transitive_compile_jars = java_provider.transitive_compile_time_jars | ||
runtime_jars.append(java_provider.transitive_runtime_jars) | ||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again the whole conditional as above but even if I’m wrong why silently ignore and not fail?
okay, @ittaiz I think I've addressed your comments. Thanks for the quick look! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m concerned about the “if”.
Previously we supported http_file, now we don’t but it’s not explicit.
People will not easily know.
For us (Wix) specifically this isn’t a problem but I’m concerned for the wider population.
Wdyt?
I have a thought, |
@ittaiz I’ll try that tomorrow. Maybe the same approach to not generate the java jar when we know we don’t need it. |
actually, @ittaiz I'd like to not yet fail and plumb the booleans through. This will be a nontrivial change to wire that optionality down to the bottom of several collection methods and it is throw away work. Next, several places in the code were already lax in that they probed for expected shape and ignored things that don't match the shape. Let's steer towards requiring providers at the bazel level and not probe anywhere, directly access Can we merge this as is to unblock? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last suggestion- wdyt about adding at least a bold paragraph to the readme saying we silently ignore jars that have no JavaInfo (for example //jar:file)? We can remove the comment when we require providers
I approved btw as a way to say that if you feel strongly about not adding the comment to the readme then you can merge as is |
okay, @ittaiz one more round... I added comments and went ahead and locked down runtime_deps, which scrooge does not use. |
👍🏽
…On Thu, 21 Jun 2018 at 1:39 P. Oscar Boykin ***@***.***> wrote:
Merged #523 <#523>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#523 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF46MFvQDsIqWK8PMankRZm6d1cF-ks5t-s8igaJpZM4UqGd5>
.
|
since we put the scrooge srcjar into deps, we wind up putting all the srcjars as well as the thrift srcs on the classpaths. This is not what we want.
I am having trouble using this rule in a repo with a very large number of thrifts because the classpaths are getting too large. I will do a run with this and see if it bypasses.
cc @ianoc @ittaiz